fix(api): resync sso provider schemas - #6058

TL;DR

supabase sso list dies with SchemaError(Missing key at ["items"][0]["domains"][0]["id"])

The platform dropped id from saml and domains[] on the sso provider responses on Jul 21. Go absorbed it same day in #5897
we didn't, since our openapi.json still marks domains[].id required and we decode strictly.
show and update's preflight hit the same field, remove hits saml.id one earlier
they surface one at a time because decoding stops at the first missing key, which is why it reads like a regression of #5475.

The snapshot never healed because that same spec change tripped the two saml/required test ops in
openapi-overrides.json, the first sync run after the change, and api-package-sync has been red every run since
so this unblocks that too.
The two overrides go with it: upstream adopted both, there's nothing left to relax, and keeping them only re-arms the same hard stop next time.

Resynced the five schemas from the live spec and regenerated
byte-identical to a fresh pnpm generate, so the next sync won't fight it.
Nothing read the dropped fields, and sso.go-payload.ts already mirrored Go's struct without them, so -o yaml|toml is unchanged and -o json now drops them the way Go does, even if a project still echoes them.

Two things the resync pulled in that are worth naming rather than leaving for a reviewer to spot....
the attribute_mapping…default union flipped oneOf → anyOf upstream, so the generated Schema.Union loses { mode: "oneOf" } — inert here, the four branches are disjoint so no value can match two.
And the fixture churn: the sso suites were feeding themselves saml.id/domains[].id that the API doesn't send,
so they'd have stayed green however stale the schema got. They use the real payload shape now....

refs

• closes supabase sso list fails with SchemaError(Missing key at ["items"][0]["domains"][0]["id"]) #6051
• chore: sync API types from infrastructure #5897 (the same ten fields removed on the Go side)